[ワークショップ] 生成AIを使ったクラウドのトラブルシューティングについて学ぶ「Troubleshooting in the cloud with generative AI 」に参加しました #AWSreInvent #SUP312-R

リテールアプリ共創部の中野です。

AWS re:Invent 2024 のワークショップである「Troubleshooting in the cloud with generative AI [REPEAT]」に参加してきましたのでレポートします。

ワークショップの概要

概要（re:Invent 2024 イベントサイトより抜粋）

How do you troubleshoot large-scale applications running on AWS? Using time-tested troubleshooting methods and AWS services, including generative AI offerings, learn to accelerate the diagnosis and resolution of operational issues. Amazon CloudWatch, AWS Config, AWS X-Ray, and Amazon Q allow you to set up appropriate proactive and reactive monitoring, automate mitigations, and enhance your troubleshooting. In this workshop, choose your preferred domain—compute/networking, containers, databases, or serverless/DevOps—and then work on triaging issues using generative AI, best practices, and techniques shared during the workshop. You must bring your laptop to participate.

タイトル

SUP312-R | Troubleshooting in the cloud with generative AI [REPEAT]

スピーカー

Bhavani Kanneganti
David Schliemann
Mohammad Shaflullah

LEVEL

300 – Advanced

ワークショップ内容

私の行ったワークショップの内容としては、VS Code 上で利用できる Amazon Q Developer のチャット機能と Amazon Q Business を使って、AWS 環境で発生した問題のトラブルシューティングをおこなうという内容でした。

ワークショップで提供されたトラブルシューティングのコンテンツは以下の通りでした。
4 つのシナリオの中から 1 つ選ぶ必要がありました。

• DevOps and Serverless Troubleshooting
• Containers (ECS Troubleshooting or EKS Troubleshooting)
• Networking and Web Services troubleshooting
• Database troubleshooting

冒頭 30 分程度で AWS のサポートチームから AWS の可観測性を高めるためのサービスの紹介や生成 AI を活用したトラブルシューティングの事例の紹介がありました。

特に印象に残ったのは、確証バイアスについての説明でした。

ある問題の調査に取り組む際、仮説を立てながら調査を進めるのがトラブルシューティングとしては一般的なアプローチだと思います。
一方で、それを裏付ける情報を探す傾向が人間にはあるとのことです。
たとえば、ウェブアプリケーションが高いレイテンシーを調査していて、Web サーバーの CPU が高いことがわかってます。
このとき、短絡的に CPU の上昇はレイテンシーの原因だと結論付けてしまうのはよくないパターンです。
メトリクスのないところも調べて、調査して他にも原因がないか多角的に調査する必要があります。

確かに個人的にも、仮説検証を進める中で、メトリクスやログがない部分は深く調査せず、見えている部分だけで結論付けてしまうことがありました。結果的に別の原因だったということもあったので、納得がいきました。

残りの 1.5 時間という制限の中で、トラブルシューティングのシナリオを解きます。
一番業務でやっていることに近しいコンテンツである「DevOps and Serverless Troubleshooting」を選択してみました。

CodePipeLine 上に構築されたサーバレスリソースのデプロイの問題を解決するというミッションでした。

このワークショップでは、Visual Studio Code に導入した Amazon Q を最大限活用して CodePipeline のどの部分にエラーの根本原因があるかデバッグしていきました。

コードを選択して Amazon Q の Chat 上にプロンプトとして送ることができました。
英語で欲しい回答のプロンプトを書きました。
CloudFormation のコードのどの部分に原因があるか、さらに解決方法について教えてもらえるか、問い合わせることで回答を得ることができました。
（残念ながら日本語でプロントを書いてみましたが、現時点では回答が得られませんでした）

さらにコードの一部を修正するように指示することもできるようです。

さいごに

本日は Amazon Q を使ってサーバレス環境のトラブルシューティングを学ぶ「Troubleshooting in the cloud with generative AI [REPEAT]」に参加した様子をレポートしてみました。

普段は、Cursor や GitHub Copilot などのエディタでトラブルシューティングをやっていたので、Amazon Q を活用したのは初めてでした。
Amazon Q 自体、AWS に関する情報に対する回答の精度が高いため、AWS にピンポイントを絞って利用する場合に活用するのは 1 つの手札としていいなと思いました。

この記事が誰かの参考になれば幸いです。